Tata Pay | Rbiswas Portfolio

Built the payment experience that turned Tata Neu from a commerce app into a financial entry point.

The work focused on reducing ambiguity in UPI actions, improving multi-bank clarity, and creating failure states that helped users recover instead of abandoning the flow.

Estimated outcome from usability validation: ~42% fewer steps in core payment journeys, ~22% higher task completion, ~28% lower confusion in failure states, and ~12% repeat-usage lift among test users.

Context & Scale

Designed for a high-volume UPI ecosystem inside a multi-service super app.

Tata Pay had to work inside India’s UPI rails, where users expect speed, bank-level trust, instant confirmation, and graceful handling of failures. The product also had to sit naturally inside Tata Neu, where commerce, loyalty, and financial services share the same user journey.

Ecosystem pressure

Payments, rewards, lending, and services in one flow

Trust barrier

Users compare every screen to bank-app reliability

Scale challenge

Error handling must work for first-time and power users

Platform challenge

One design language across mobile and web

Problem Definition.

The issue was not “how do we add UPI?” The issue was how to make payment behavior feel trustworthy, recoverable, and consistent across a fragmented financial journey.

01 · Friction

Too many decisions before payment

Users had to interpret bank choice, UPI state, and recipient context before they could act. That slowed intent-to-pay conversion.

02 · Fragmentation

Bank account logic felt scattered

Multiple accounts and UPI handles created uncertainty about which account would be used, especially during repeat payments.

03 · Failure opacity

Failed transfers looked final

Users needed status clarity, next-step guidance, and reassurance. Without it, they repeated actions or exited the app.

04 · Trust

Fintech trust is earned in micro-moments

A small wording issue or weak error state could reduce confidence more than a visual polish could recover.

Key Design Decisions.

Every decision was made to reduce ambiguity, lower the cost of mistakes, and support scale without adding unnecessary cognitive load.

Decision 01

Problem: Payment intent was hidden behind banking language.

Decision: Reframed the primary actions around user intent: send, receive, pay, and manage accounts.

Why: Users do not think in product modules; they think in outcomes. A task-led structure reduced interpretive load at the point of action.

Impact: ~40% reduction in navigational steps and faster entry into the core payment flow.

Decision 02

Problem: Multi-bank users could not see what was active.

Decision: Built persistent bank-state visibility, account prioritization, and explicit switching patterns.

Why: The highest-risk failure in UPI is not failure itself; it is uncertainty about which account or mandate is being used.

Impact: ~25% improvement in task confidence and fewer account-selection errors during repeat use.

Decision 03

Problem: Failure states felt like dead ends.

Decision: Designed actionable error states with timing, reason, and recovery guidance instead of generic decline messaging.

Why: In fintech, users need proof that the system is still working. Clear recovery paths reduce anxiety and repeated taps.

Impact: ~30% improvement in failure clarity and lower abandonment after transaction interruptions.

Decision 04

Problem: Experience had to scale across platforms.

Decision: Standardized tokens, spacing, hierarchy, and component rules across mobile and web.

Why: Consistency is a trust signal in financial products. Reuse also improves delivery speed and reduces implementation drift.

Impact: Faster design handoff, fewer UI inconsistencies, and a more scalable fintech system.

Core Flows.

The critical flows were designed around speed, recoverability, and bank-grade clarity.

Send Money

Before vs After

Before: users had to decode bank context, amount entry, and confirmation sequencing. After: the flow began with intent, surfaced the active account, and reduced interruption points.

Before

Multiple checkpoints, unclear navigation labels, and high interaction cost for simple transfers.

After

Single-path flow, direct confirmation cues, and reduced opportunity for user error.

Complexity reduction

~45% fewer interactions in the refined journey, based on prototype testing and task analysis.

Executive takeaway

The experience made the primary action obvious without hiding risk or payment state.

Bank Linking

Multi-bank usage

Users often returned to the app with different banks active, so the product had to explain what was connected, what was default, and what could be switched safely.

Visibility

Show linked banks, active bank, and UPI status in one place.

Control

Allow switching without forcing users to restart the journey.

Reliability

Use explicit status labels to prevent duplicate linking or repeated attempts.

Failure Handling

The most important fintech flow

We treated failures as product moments, not system alerts. Each state needed to answer what happened, whether funds moved, and what the user should do next.

Before

Generic error text, no next step, and repeated retries that increased anxiety.

After

Clear state, readable explanation, retry guidance, and support escalation where needed.

Result

~33% better failure comprehension and lower duplicate attempts during interrupted transfers.

Risk control

Reduced false confidence by making transaction status explicit at every stage.

System Thinking.

The work was not only about screens. It was about building a reusable payment system that could scale across product teams.

Design tokens

Defined color, spacing, type, and state tokens so components could be reused consistently across mobile and web without visual drift.

Component reuse

Turned payment patterns into repeatable modules: bank cards, account status chips, error banners, confirmation sheets, and trust cues.

Cross-platform consistency

Maintained one hierarchy and one interaction model so users did not have to relearn the product when moving between platforms.

Scalability decisions

The system was structured to support future modules like lending, gold, insurance, and offers without redesigning the foundation.

This kept financial products visually coherent while allowing business teams to launch new services faster.

Delivery advantage

A stable design system reduced rework during engineering implementation and made design reviews more decisive.

Estimated benefit: ~20% faster design-to-dev alignment on recurring payment patterns.

Metrics & Impact.

These outcomes are estimated from prototype validation, usability review, and flow simplification analysis.

~42%

Reduction in steps

Core payment journeys became materially shorter.

~22%

Improvement in task completion

Users completed flows with fewer drop-offs.

~28%

Reduction in confusion

Clearer account and status cues improved comprehension.

~12%

Repeat-usage lift

Trust and clarity improved return intent.

Operational impact

Better failure guidance and clearer account states reduced support dependency, especially for basic “what happened?” queries after a transfer interruption.

Business impact

A more trustworthy payment layer increased the likelihood that users would continue inside Tata Neu rather than exiting to a bank app for transactions.

Trade-offs & Constraints.

Fintech design is always a balancing act. Every simplification had to survive compliance, security, and engineering reality.

Speed vs security: The flow had to remain fast without hiding risk indicators or confirmation cues.

Simplicity vs compliance: Legal and banking requirements constrained how much we could reduce in the UI.

UX vs technical limitations: Some states depended on backend outcomes, so the interface had to explain uncertainty without overpromising.

Learnings.

What worked was treating trust as an interaction problem, not a brand problem. Once the flow became predictable, the product felt more premium and more bank-like.

What did not work was assuming users would understand system terminology without translation. In payments, clarity always beats completeness.

What I would change

Invest earlier in backend-visible status models for better end-to-end failure transparency.
Add more contextual help for first-time UPI users at the moment of bank linking.
Extend the design system into fraud and dispute flows sooner.